home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / isn / 92mar.min < prev    next >
Text File  |  1993-02-17  |  9KB  |  214 lines

  1. This is only a rough draft - Megan 04/10/92
  2.  
  3. 23rd IETF meeting -- San Diego, CA
  4. Working Group on Internet School Networking
  5. March 17, 1992    1:30 -- 3:30 p.m.
  6.  
  7. Co-Chairs: Art St.George (present),
  8. stgeorge@bootes.unm.edu; Connie Stout,
  9. connie.stout@tenet.edu; John Clement (present),
  10. clement@educom.edu
  11. General mailing list for ISN-WG: isn-wg@unmvm.unm.edu
  12.  
  13. A list of those attending the session is appended to this
  14. document.
  15.  
  16. Minutes
  17.  
  18. Specific discussion around the major agenda topics is
  19. summarized below in sections 1) and 2).  A number of
  20. general issues were addressed during the meeting, and are
  21. summarized briefly first.
  22.  
  23. Joyce Reynolds <jkrey@isi.edu> mentioned that there is
  24. considerable interest in international circles, especially in
  25. Europe, in what this working group is doing, and that
  26. products from the WG will be scrutinized attentively
  27. overseas.
  28.  
  29. Among the more general issues (exceeding technical
  30. boundaries) raised at least briefly during the session were:
  31. the need to provide persuasive arguments for educators to
  32. use with school administrators, to support both initial access
  33. and expansion of networking capabilities; the continuing
  34. need for postsecondary institutions to remain involved in
  35. helping schools with connectivity, whether as sources of
  36. guest accounts, for technical expertise and support where
  37. other mechanisms are not yet in place, or as sources of
  38. collaboration on connectivity or content problems.
  39.  
  40. The issue of having the ISN-WG contribute to providing
  41. technical consulting capabilities to K-12 groups and
  42. institutions was discussed briefly.  Although no definite
  43. resolution was offered, after the meeting it was suggested
  44. that a roster of persons willing to respond to technical
  45. questions might be prepared and offered as part of the FAQ
  46. resource (cf. item 2) below), with the possibility that these
  47. individuals might provide further technical consultation.
  48. One condition of listing in the roster would be that good
  49. questions to roster members would be added by them to the
  50. FAQ list.
  51.  
  52. Denis Newman <dnewman@bbn.com> offered that there are
  53. many more (both local- and wid-area) networks in place in
  54. schools for administrative uses than there are instructional-
  55. use networks.   He  stipulated that, if administrative
  56. networks can be linked into the Internet -- as FIRN is in
  57. Florida -- overall connectivity can be substantially advanced.
  58. Denis suggested that the working group examine the issues
  59. involved in extending administrative LANs and WANs for
  60. instructional use; in particular, the group might consider
  61. addressing security questions, and look at the reality of risks
  62. entailed in carrying administrative and instructional traffic
  63. over the same networks, especially ways to minimize the
  64. risk of unauthorized access.
  65.  
  66. 1)  Review of connectivity alternatives and growth paths.
  67. Mailing list for this discussion: connect@unmvm.unm.edu
  68.  
  69. A draft document prepared by Pat Burns and Ed Zachmann
  70. of Colorado State University (available on connect archives
  71. in Postscript format, or contact Art St.George for fax) was
  72. distributed to attendees, and served as a basis for extensive
  73. discussion during the meeting.
  74.  
  75. John Clement presented a networking growth path from the
  76. viewpoint of educator practices.  Ensuing discussion pointed
  77. out that the Burns and Zachmann paper lacked an initial
  78. connection model, what might be called Level 0 (the present
  79. paper begins with Level 1).
  80.  
  81. Burns and Zachmann's Level 1 connectivity models (cf.
  82. especially Figures 3a and 3b) led to a consensus that both
  83. figures and their explanatory text needed relatively minor
  84. but significant revisions.
  85.  
  86. Extensive discussion of the need for continued connection
  87. capability for the existing base of computers in schools (often
  88. machines of reduced capacity) led to an expressed consensus
  89. that such capability should be maintained in the near future
  90. (under Level 0 connection options), but should be eliminated
  91. over time as more advanced connection levels predominate.
  92. The minimum hardware capability for full Internet access to
  93. be supported would be Apple Macintosh machines or MS-
  94. DOS machines running Windows.
  95.  
  96. Joe Blackmon <blackmon@ncsa.uiuc.edu> summarized his
  97. experiences in putting together full (56kbps) Internet
  98. connections for finalist schools in the SuperQuest
  99. competition at lowest possible costs, and offered to share a
  100. document he is preparing for SuperQuest on the subject.
  101.  
  102. Discussion of Levels 2-4 (Figures 4-6 of Burns and Zachmann
  103. paper) connection models was relatively brief.  There
  104. seemed to be general agreement that, on first reaction (most
  105. attendants were seeing the paper for the first time at the
  106. session), the models were acceptable with relatively minor
  107. corrections, although considerable extension and
  108. clarification were requested (see below).  One point made
  109. was that the models as presented in the paper were
  110. overspecified with regard to their technical components, for
  111. the level of generality needed for a paper on connectivity
  112. alternatives.  At the very least, mention should be made of
  113. other technical alternatives.
  114.  
  115. [This was in no way presented as a criticism of the Burns and
  116. Zachmann paper, since they offered a starting point and it
  117. was appropriate to list a complete technical implementation
  118. so as to estimate costs.  But perhaps it could be presented as
  119. one example.]
  120.  
  121. Among the points raised that implied expanding the
  122. descriptions of the models:
  123.  
  124. o     guidance on the boundaries of application of each
  125. model:  when each becomes inappropriate in given school
  126. contexts.  For example, model 1 might apply to 3-8 machines
  127. in a school, and would not work for more than eight
  128. machines.
  129.  
  130. o     specification of what kinds of Internet capabilities are
  131. available for each model:  i.e., model 1 offers telnet (remote
  132. login) via an interface menu item, but no direct telnet
  133. capability, and would allow access to WAIS via Simple
  134. WAIS but not the installation of WAIS client software, etc.
  135.  
  136. o     more complete specification of what is required at the
  137. Internet node/connection point for each model;
  138.  
  139. o     cost estimates for moving from one model to the next,
  140. and stipulation of what equipment would be no longer
  141. needed and could be used elsewhere;
  142.  
  143. o     specification of personnel, time and training
  144. requirements for installation, support (including time for
  145. administration and security protection), and maintenance.
  146.  
  147. Jeff Hayward (jhayward@utexas.edu--ART I'M NOT SURE
  148. THIS ADDRESS IS RIGHT, DOING IT FROM MEMORY
  149. AND WHOIS IS NO HELP..) agreed to lead an effort to
  150. respecify the models on the basis of the Burns and
  151. Zachmann paper and its discussion, and to amplify their
  152. written description, and to prepare a draft before the end of
  153. the IETF meeting if possible.
  154.  
  155. It was agreed that a revised draft document would be made
  156. available on <connect@unmvm.unm.edu>, and that it would
  157. be revised once more from feedback on the list.  A twice-
  158. iterated draft might be available in advance of the Twenty-
  159. Fourth IETF, in Boston in July.
  160.  
  161. 2)  Development of an FAQ ("frequently-asked-questions)
  162. archive on school connectivity issues.  A new mailing list
  163. will be formed for this issue
  164.  
  165. Discussion initially focused on identifying sources of
  166. information and materials from which a set of FAQs and
  167. candidate answers might be developed.  KIDSNET and
  168. EDTECH lists were mentioned, and there are many others.
  169. A number of attendees offered to help round up relevant
  170. materials:
  171.  
  172. Gene Hastings <hastings@psc..edu>
  173. Peter Deutsch  <ART, DO YOU HAVE HIS EMAIL
  174. ADDRESS?>
  175. Rob Reilly <rreilly@athena.mit.edu>
  176.  
  177. Art St. George and John Clement offered to assemble the
  178. materials located into a preliminary archive.
  179.  
  180. Volunteers were solicited to edit the archive and
  181. review/revise answers to the questions.  The following were
  182. dragooned into volunteering:
  183.  
  184. Tony Rutkowski <amr@nri.reston.va.us>
  185. Joe Blackmon <blackmon@ncsa.uiuc.edu>
  186. Tracy LaQuey <CURRENT EMAIL, PLEASE?>
  187. Michael Marcinkevicz <mdm@csu.net>
  188.  
  189. John Clement will also ask Al Rogers of FrEdMail to
  190. volunteer or suggest one of the FrEdMail sysops to
  191. volunteer.
  192.  
  193. By the next IETF meeting, it was agreed that a preliminary
  194. FAQ archive would have received an editing pass and
  195. would be available for examination and revision.
  196.  
  197. The following preliminary set of categories is offered for
  198. consideration for the FAQ list:
  199.  
  200. o     why should K-12 educators and schools connect to the
  201. Internet?
  202. o     modes of access
  203. o     costs
  204. o     support issues, including maintenance, access rules,
  205. security
  206. o     sources of information
  207. o     troubleshooting
  208. o     glossary of essential terms
  209. o     technical specifications
  210. o     technical consultants roster:  people willing to respond
  211. to questions, or possibly provide further consultation
  212.  
  213.  
  214.